다운로드 횟수 제한 설계
실질적인 운영상황에서는 단기간 내의 무분별한 다운로드 시도 및 수십차례 이상의 다운로드 시도는 파이어베이스 스토리지의 폭발적인 비용증가로 이어질 수 있습니다.
개요
MVP 완성 이후 지인들을 대상으로 QA를 진행한 결과, 다운로드 진행 여부를 Toastr를 통해 안내하고 있었음에도 모바일 환경에서는 의도하지 않은 연속 터치가 발생하는 사례가 확인되었습니다.
예를 들어 한 명의 사용자가 하나의 파일을 다운로드하는 과정에서 2~3회의 추가 요청이 발생할 경우, 개별 요청 자체는 크지 않더라도 실제 운영 환경에서는 Firebase Storage 비용 증가로 이어질 수 있는 상황이었습니다.
특히 해당 서비스는 전국 단위 매장에서 사용되는 구조였기 때문에, 소수 사용자의 반복 요청 역시 누적될 경우 무시하기 어려운 비용으로 이어질 가능성이 존재하였습니다.
따라서 고객사와의 협의를 통해 다운로드에 대해서는 단순 만료 시간뿐만 아니라, 다운로드 가능 횟수 역시 함께 제한하는 정책을 도입하였습니다.
이를 통해 의도하지 않은 반복 요청을 줄이고, 스토리지 비용을 보다 안정적으로 관리할 수 있도록 개선하였습니다.
단기간 내의 요청
초기 구현 단계에서는 단기간 내의 중복 다운로드 요청을 방지하기 위해, 프론트엔드에서 다운로드 버튼을 비활성화하는 방향을 우선 검토하였습니다.
하지만 실제 운영 환경은 모바일 기기를 포함하고 있었으며, 네트워크 상태가 불안정한 상황에서는 사용자가 요청이 정상적으로 처리되었는지 판단하기 어려운 경우가 존재하였습니다.
이 경우 사용자는 동일한 버튼을 여러 차례 반복하여 터치하게 되고, 그 결과 의도하지 않은 다운로드 요청이 연속적으로 발생할 수 있었습니다.
특히 다운로드 횟수 자체가 제한되는 구조에서는, 이와 같은 중복 요청이 모두 다운로드 이력으로 기록될 경우 사용자는 실제로 파일을 정상적으로 받지 못했음에도 다운로드 가능 횟수를 소진하는 문제가 발생할 수 있었습니다.
따라서 최종적으로는 프론트엔드 차원의 버튼 비활성화와 별개로, 서버 측에서도 일정 시간 내 반복 요청을 무시하도록 처리하였습니다.
이를 통해 단기간 내의 중복 요청은 다운로드 횟수에 포함하지 않도록 하였으며, 사용자 경험과 운영 비용을 동시에 고려할 수 있는 방향으로 개선하였습니다.
왜 복합적인 제한 방식을 선정하였는가
다운로드 횟수만을 기준으로 파일을 삭제할 경우 다음과 같은 문제가 발생합니다.
- 다운로드 이력이 없는 파일은 장기간 저장될 수 있음
- 사용 여부와 관계없이 스토리지가 누적됨
- 운영자가 직접 정리하지 않는 이상 비용 증가 가능성 존재
반대로 만료일만을 기준으로 삭제할 경우에는
- 특정 사용자가 단기간 내 반복 다운로드를 수행할 수 있음
- 예상보다 많은 트래픽이 발생할 수 있음
- 공유 링크가 외부에 확산될 경우 통제가 어려움
따라서 본 시스템에서는
- 단기간 반복 요청은 횟수 제한으로 제어
- 장기간 미사용 파일은 만료일 기준으로 정리
라는 두 가지 정책을 동시에 적용하였습니다.
이를 통해
- Storage 사용량 관리
- 비정상 다운로드 방지
- 운영 비용 예측 가능성 확보
를 모두 만족하도록 설계하였습니다.